COMMENT ⊗   VALID 00005 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	∂28-Feb-77  1204	FTP:LEFAIVRE at RUTGERS-10	NEWEST COMPILER   
C00004 00003	∂15-Mar-77  1913	FTP:LEFAIVRE at RUTGERS-10	YET ANOTHER COMPILER BUG    
C00008 00004	∂05-Nov-77  0624	FTP:LEFAIVRE at RUTGERS-10 	YET ANOTHER COMPILER BUG   
C00015 00005	∂10-Jan-78  0053	FTP:LEFAIVRE at RUTGERS-10 	New RUTGERS/UCI LISP Taking Shape    
C00022 ENDMK
C⊗;
∂28-Feb-77  1204	FTP:LEFAIVRE at RUTGERS-10	NEWEST COMPILER   
Date: 28 Feb 1977 (Monday) 1503-Est
From: LEFAIVRE at RUTGERS-10
Subject: NEWEST COMPILER
To:   DIFFIE at SU-AI

Whit-

I recently found another obscure bug in the compiler, making the version
you have obsolete already (!).  The corrected version is in LSP:ILISPC.LSP.
Note that I have finally released the entire RUTGERS/UCI LISP system,
including ILISP itself (with the new prettyprinter, lots of new functions,
↑C interrupt routine, etc.), ILISPC (with bug fixes, in-line ERRSETs, etc.),
and ILISP versions of PLNR, FUZZY, and CNVR (CNVR not quite ready yet).
All of the new stuff (including new features of the compiler) is described in
LSP:ILISP.MAN, which should magically appear in about an hour (I am making
some final editing changes).  I don't know if you have a locally-hacked
UCI LISP out there or what, but you might want to look at RUTGERS/UCI LISP
for use at Stanford.  If you do, send me a tape and I'll copy the LSP:
library onto it.

-Rick

∂15-Mar-77  1913	FTP:LEFAIVRE at RUTGERS-10	YET ANOTHER COMPILER BUG    
Date: 15 Mar 1977 (Tuesday) 2214-Est
From: LEFAIVRE at RUTGERS-10
Subject: YET ANOTHER COMPILER BUG
To:   DIFFIE at SU-AI

Whit-

My new version of the compiler is now affectionately (?) known at
Rutgers as the "BUGLESS COMPILER" because of the assurances I keep
giving people that I've finally (underlined) found the LAST BUG!
Well, another one turned up last weekend.  Its good that the system
is now officially released, as more people are giving it a workout.
Following this message is a new version of the compiler, followed
by an updated CTEST (the latest bug is RB9).  I think it's easier
to just send the whole thing over this way instead of sending the
changes and having you incorporate them in your version.

-Rick

∂28-Jul-77  1752	FTP:LEFAIVRE at RUTGERS-10	Another ILISPC bug bites the dust
Date: 28 Jul 1977 (Thursday) 2050-Est
From: LEFAIVRE at RUTGERS-10
Subject: Another ILISPC bug bites the dust
To:   DIFFIE at SU-AI

Whit-

Just discovered another bug in the compiler I sent you a while ago.  As
this one was of my own doing, I feel especially obligated to let you know
about it.  It came about because I moved the old GUARDLOCS code and the
CLEAR1 inside of P2COND1, so it could be called both by P2COND and BOOLCOND.
In so doing, I inadvertantly masked out P2PROG's copy of MINDEPTH, so that
if a CLRPVARS is delayed until after a COND is entered, it is possible for
the stack to be popped too far.  This bug has been in for about a year, and
it only made itself known today, so it is rather rare.  My fix was to split
P2COND1 into two PROGs, with the second binding MINDEPTH after the CLEAR1 is
done in the first.

We also discovered that if a special var has the same name as a function
and it is called before the function is defined or declared, the call is
compiled as a variable (as one would expect).  However, the user is not
warned about this when the function is finally defined.  I put a check in
for this, along with a couple of other little fixes.

If you still have plans to use this compiler, I will be happy to FTP it
over (or send me a tape and you can have the whole super RUTGERS/UCI LISP
system - it's now spreading to other TOPS installations around the country).

-Rick

∂05-Nov-77  0624	FTP:LEFAIVRE at RUTGERS-10 	YET ANOTHER COMPILER BUG   
Date:  5 Nov 1977 (Saturday) 0921-Est
From: LEFAIVRE at RUTGERS-10
Subject: YET ANOTHER COMPILER BUG
To:   DIFFIE at SU-AI

Whit-

Cris Perdue at CMU uncovered another bug in the LISP compiler.  The simplest
manisfestation seems to be a function like:

	(DE TST (X) (FUNC (CAR X) (FUNC2 (CAR (CAR X)))))

The problem is that when CSTEP goes to load the first CAR, COPT tells it
that it is equivalent to the second and needn't be recomputed.  This
association is established via VARLIST.  But when CSFUN is called to
clear the first CAR off of CCLST, it calls ILOC instead of ILOC1, and
ILOC doesn't check VARLIST, so another call to LOADCARCDR is made.
Since the second CAR has already been loaded and REMOVEd, LOADCARCDR
decides it must reload the CAR, but X is long gone and . . . BANG.

I don't know if this bug has been around for awhile or not.  None of
my fixes affected this stuff directly, but some other fix might have
impacted on it.  Anyway, the fix appears to be to change CSFUN to call
ILOC1 instead of ILOC:

	(DFUNC (CSFUN L AC)
	 (PROG (Y) (AND (SETQ Y (ASSOC (CAR L) LDLST)) (ILOC1 Y AC))))

(The LOADCARCDR in CSFUN is now done by ILOC1 if necessary).

I've also decided to fix a problem with the in-line MAP functions.  The
interpreter takes the CDR BEFORE it applies the function, so if the
function does a RPLACD things are ok.  The compiled code tries to take
the CDR AFTER the function application, so a RPLACD screws things up.
I'm going to fix the compiler to do it the way the interpreter does.
While I'm at it I'm going to change MAPCAR, MAPLIST, MAPCONC, and
MAPCON to use TCONC and LCONC instead of doing it all in-line - should
save some space.

There is a growing effort to try and standardize Stanford/UCI/Rutgers
LISP as the major LISP after INTERLISP and MACLISP, headed by Jim
Meehan at UCI, Cris Perdue at CMU, and myself.  We are discussing
such controversial topics as just what should be in the system and what
should be in library packages, and how we can work jointly on a comprehensive
manual.  Would you (or someone else there) have any interest in joining
such an effort?


∂20-Nov-77  1816	FTP:LEFAIVRE at RUTGERS-10 	Another compiler bug  
Date: 20 Nov 1977 (Sunday) 2114-Est
From: LEFAIVRE at RUTGERS-10
Subject: Another compiler bug
To:   DIFFIE at SU-AI, CRIS.PERDUE at CMU-10A

I just found another bug in the LISP compiler.  It has me a little worried,
as it seems too simple to have been around for a long time, but I'm not
sure if any changes of mine over the past year caused it.  It involves
constructs like the following:

	(DE TST (X) (COND [(EQ X (SETQ X 5)) (FUNC X)]))

In my version of the compiler BOOLEQ1 gets screwed up after it evaluates
the two arguments to EQ.  The old X is sitting in the PDL and the new X
is in a register, but since a SAVEACS is done after removing the args from
LDLST, the new X is saved on top of the old X (which looks like garbage),
and the comparison always compares 5 with 5.

It took me awhile to come up with a fix, as the logic interacts heavily
with the stuff in P2COND1 which tries to insure that no permanent
pushes need to be done inside a COND.  The following seems to work:

	(COND [(AND (DVP (SLOTCONT AC))
		    (NUMBERP MEM)
		    (LESSP MEM 1))
	       (SETQ ARG1 (SLOTCONT MEM))
	       (LOADARG (SETQ MEM (FREEAC)) ARG1)])

This goes right before the SAVEACS in BOOLEQ1.  The idea is that if the
object in the AC is still important after REMOVEing it, i.e., it needs
to be saved somewhere by the SAVEACS, we should get the other arg into
an ac to make sure it isn't taking up a pdl slot into which the first
arg could be placed.

This looks like a typical kludge which could either cause some other
problems or doesn't solve the problem in all cases, but until someone
comes up with something better . . .

∂10-Jan-78  0053	FTP:LEFAIVRE at RUTGERS-10 	New RUTGERS/UCI LISP Taking Shape    
Date:  9 Jan 1978 (Monday) 2230-EST
From: LEFAIVRE at RUTGERS-10
Subject: New RUTGERS/UCI LISP Taking Shape
To: @LISP.ARP[3442,46] at RUTGERS-10:

Dear LISPer:

This letter is being sent to all known users (and potential users) of
RUCI LISP (RUTGERS/UCI LISP),  which is now in use at around 25 sites
and continues to spread.  I would like to thank those of you who have
notified  me of bugs and made suggestions for improvements.  A number
of bugs have been corrected over the past year -  I  can't  guarantee
that there are none left, but they are getting more and more obscure.
A number of improvements have also been made - I can't even begin  to
describe them all here, but a few are mentioned below.

The  real  reason  for this note is to inform you that in addition to
improvements to existing modules and  a  host  of  new  functions,  a
couple  of  changes  have  been  made  which  affect  existing files.
This will cause  some  temporary  inconvenience  (although a  MIC/SOS
conversion file will be provided), but I feel the final product  will
be worth it.  The changes include:

- The system is now called LISP, with the compiler called LISPC.  The
initialization  file  is  now  LISP.INI,  and  you  can  also  have a
LISPC.INI, PLNR.INI, CNVR.INI, or FUZZY.INI.

- The QUOTE macro character has finally been changed from @ to  '  to
make  us compatible with the rest of the LISP world.  @ will continue
to be recognized (unless it is MODCHRed), but the prettyprinter  will
now output '.

-  The  comment  functions  have  been  changed to ; and ;; (* is now
equivalent to *TIMES).  (; ...) comments are printed off to the right
of  the  listing,  and  (;;  ...) comments are printed at the current
indentation level.

- The "ignored CR/LF" character used  to  break  atoms  over  a  line
boundary is now ~ (tilde - ASCII 176).  ↑Y, like ↑Z before it, caused
problems on certain terminals - they will continue to  be  recognized
on  input  so  that  existing  files  can  be read, but ~ will now be
output.  Because of the strange handling of  ASCII  176  in  monitors
prior to 6.03, I am hoping that no one has files containing tildes.

-  The  default  integer  base  is  now  10.,  with  *NOPOINT=T  (but
*NOPOINTDSK remains NIL so that files can be dumped and read back  in
correctly).

-  The  old  CURRCOL is now called CHRPOS - CHRPOS and CHRCT now read
the actual carriage position of the TTY, so it doesn't matter whether
the  last  input  line was terminated with CR or ALTMODE (this is now
used to provide a nicer top-level).

- Lower-case letters in atomic symbols will now be  raised  to  upper
case  (unless  slashified  or  in a string) if *RAISE=T (*RAISEDSK is
used for file input).

- There  is  a  new  MACROEXPANSION  feature  which  can  be  set  to
automatically  save  a  macro  expansion so that it is only done once
(its operation is transparant to the user).  Makes a  big  difference
for complex macros.

- Some new code from Texas supporting SFDs and random access input is
now being tested.

-  There is a new SORT/MERGE package from CMU, a string concatenation
function, a way to control the file protection used  for  new  files,
some new macros, and a lot of other generally useful stuff.

I  hope  to  have  the  new  system  completely  tested and ready for
distribution in February, and have thus been sitting on the  tapes  I
now  have.  Others are welcome to send a tape, or if you prefer, drop
me a note and I'll send you the revised Rutgers documentation and you
can  see  for  yourself  what's there (although you won't see the bug
fixes and the many undocumented internal improvements). There is some
hope  that  a  comprehensive manual will be written this year, but no
one should hold their breath waiting for it.

As usual, questions or comments are welcome.

					- Prof. Rick LeFaivre
					  Computer Science Dept.
					  Hill Center, Busch Campus
					  Rutgers University
					  New Brunswick, NJ  08903